iT邦幫忙

2026 iThome 鐵人賽

DAY 3
0
自我挑戰組

踏入品質保證工程之路:QA 新手如何善用 AI 與開發者工具系列 第 3

「要友善」無法被爭論,也無法被測試

  • 分享至 

  • xImage
  •  

在 Aurora Shop 事件——AI 客服助理錯誤地告訴客戶一件不可退貨的商品可以退貨——之後,修掉眼前這個 bug 只能解決一部分問題。更大的 QA 問題其實更有意思:我該如何定義一個「好的 AI 回應」究竟長什麼樣子? 對傳統軟體而言,預期行為往往是確定性的:我點一個按鈕、送出一個有效的請求,然後期待一個特定的狀態改變或 API 回應。然而對對話式 AI 來說,輸出可以有所不同卻依然是正確的。兩個答案可以用完全不同的字句,提供一模一樣的資訊。這意味著我無法直接斷言 actual_response == expected_response。我需要的是一份行為規格,定義這個機器人必須傳達什麼、絕不可以宣稱什麼,以及當資訊不完整時應該如何表現。

假設 Aurora Shop 有 14 天退貨政策。一位七天前下單的客戶問:「我還可以退貨嗎?」助理不需要背誦一句預先定義好的句子。它可以說:「可以的,您的訂單還在我們的 14 天退貨期內」,也可以說:「因為您是七天前購買的,您仍然可以申請退貨。」兩個回應滿足的是同一個意圖。真正要緊的是:助理正確辨識出客戶的退貨意圖、使用經過驗證的下單日期、套用 14 天規則,並傳達正確的下一步。如果訂單是 16 天前下的,行為就不同了:助理應該清楚說明標準退貨期已過,而不是為了「幫忙」而悄悄放寬政策。

這正是行為規格發揮作用的地方。與其規定確切的措辭,我定義 Given–When–Then 關係:

GIVEN 購買發生在 14 天之內,

WHEN 客戶詢問該商品能否退貨,

THEN 助理應確認退貨資格,並說明任何適用的條件。

功能: AI 客服助理 / 退貨政策問答

ID Given(前置條件) When(輸入) Then(可觀察結果)
B1 訂單在最近 14 天內下達 使用者問「我可以退貨嗎?」 清楚回答可以,並說明商品必須保持原狀
B2 訂單在超過 14 天前下達 使用者詢問退貨 清楚回答已超出退貨期,並說明實際天數
B3 與退貨無關的問題 使用者詢問付款方式 不套用退貨規則;回答付款問題,或轉交人工處理

若購買發生在超過 14 天之前,助理應說明這已超出退貨期,並引用實際的時間。如果訂單日期等必要資訊無法取得,機器人不應猜測或承諾退貨。因此,這份規格測試的是可觀察的行為,而不是某一句特定的話。

「友善」不是一種測試結果

語氣帶來另一個問題,因為像*「機器人聽起來應該要友善」*這類需求很難被客觀測試。我心目中的友善可能是「當然可以!我很樂意協助您辦理退貨。」另一個人可能偏好更節制的「是的,您的訂單符合退貨資格。」兩者都可以是專業且恰當的。一個純粹建立在「我個人覺得機器人聽起來順不順眼」上的 QA 結果,會很難被其他測試人員重現。

因此,我會把「友善」轉譯成這個行銷活動的可觀察語氣標準。對 Aurora Shop 的退貨政策助理而言,回應應該有禮、簡潔、不帶批判,並以行動為導向。它應該體認客戶的疑慮而不顯得敷衍,避免責怪客戶錯過退貨期,並說明下一個可行的動作。我也可以定義不可接受的行為:爭辯性的語言、不必要的術語、在拒絕退貨時過度的熱情,或與政策矛盾的承諾。我要測試的不是機器人感覺起來友不友善,而是它是否遵循一套定義好的溝通標準。

當必須傳達壞消息時,這個區別尤其重要。如果有人在 14 天後嘗試退貨,一個過度「友善」的模型可能會為了幫忙而編造例外:「沒關係,我們大概還是可以幫您處理。」語氣聽起來很棒;正確性卻糟透了。在 QA 中,禮貌無法補償幻覺出來的政策。機器人應該在保持禮貌的同時,清楚說明限制,並在行銷活動規則允許時,提供一條有效的升級(escalation)路徑。

在不要求答案一致的前提下衡量準確性

由於 AI 回應的措辭可以變化,我會以「必須包含的事實」與「行為標準」來衡量準確性,而不是以精確的句子。對 Aurora Shop 而言,一個正確的回應應該判斷訂單是否落在 14 天退貨期內、遵循退貨政策、說明相關條件,並提供適當的下一步。

為了讓這可以被量化,我可以建立一份黃金資料集,涵蓋訂單分別在 7 天、14 天或 15 天前下達、資訊缺失、不可退貨商品,以及無關問題等案例。每個案例都有經過驗證的預期結果與明確的通過標準。得出的準確率反映的是模型在這個特定測試集上的表現,為比較模型、提示詞、知識庫或行銷活動設定的變更,提供一個可重現的基準。

建立意圖知識庫

QA 工程師可以透過協助建立***意圖知識庫(Intent Knowledge Base)*來強化這個流程——它把「客戶想完成的事」與「回覆模型被允許使用的資訊」連接起來。與其給 AI 一個模糊的指令,例如「協助客戶處理退貨」,知識庫為特定行銷活動提供的是結構化的情境。

對 Aurora Shop 而言,一個意圖可能是 RETURN_ITEM。它的知識情境會定義 14 天退貨期、退貨資格條件、已知的例外情況、必要的訂單資訊、升級規則,以及助理可以建議的動作。回覆模型隨後可以收到行銷活動專屬的情境,例如:客戶想退貨、經驗證的購買發生在七天前、此活動允許 14 天內退貨、該商品未被標記為不可退貨,而適當的下一步是引導客戶走完核准的退貨流程。

意圖與情境之間的這種分離很重要。意圖回答的是*「客戶想做什麼?」情境回答的是「應該由哪些規則與事實來主導回應?」*模型的工作則是在這些約束之下,建構出實用的自然語言回覆。QA 可以分別測試每一層:退貨意圖有沒有被正確分類?有沒有檢索到正確的活動知識?有沒有提供正確的訂單事實?生成的回應有沒有扎根在那些事實之上?

行銷活動情境還能防止一個通用的 AI 助理套用屬於別處的規則。Aurora Shop 可能有 14 天退貨政策,而使用同一個底層模型的另一個行銷活動卻可能有不同的資格規則。模型不應該依賴它的通用知識——或昨天的對話——來決定哪個政策「聽起來合理」。應該由所指派的行銷活動決定權威的情境。

從提示詞測試到行為驗證

對我而言,這改變了「測試一個 AI 聊天機器人」的意義。我不只是在聊天視窗裡打字發問,然後判斷回應「看起來好不好」。我驗證的是一條鏈:

客戶意圖

行銷活動情境

知識檢索

模型回應

可觀察行為

當某個環節失敗時,這條鏈也給了我調查的方向。一個錯誤的答案,可能來自意圖分類錯誤、情境缺失、知識過期、業務規則有誤,或是生成過程忽略了本來正確的資訊。

行為規格為這樣的調查提供了一個客觀的起點。機器人不必背誦一個完美答案,QA 也不必變成負責裁定「每一句話聽起來夠不夠開朗」的部門。相反地,我定義的是回應必須為真的事情:政策準確、使用了正確的情境、不確定性被安全地處理、下一步動作恰當,而語氣遵循可衡量的溝通準則。

這就是問***「這個 AI 回應聽起來好不好?」與問「我能證明這個回應的行為符合規格嗎?」***之間的差別。前者高度依賴個人觀感;後者產生證據——而在 QA 中,證據永遠比感覺(vibes)好辯護得多。


上一篇
從電路檢查點到軟體驗證
下一篇
你不能完全信任「綠燈」:AI 時代的風險導向 QA
系列文
踏入品質保證工程之路:QA 新手如何善用 AI 與開發者工具6
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言